Method and system for distributed key management in a secure boot environment

ABSTRACT

A methods for preparing an authenticable and verifiable image of a software module by adding to the received software module image a size and location block, an authentication block including a cryptographically protected module-specific public key and a clear-text version of the module-specific public key, and a verification block that includes a digital signature prepared from the module image. In one particular embodiment of the present invention, a next firmware-module that is to be accessed during a secure boot process is created to include a module-specific public key, a hashed and encrypted version of the module-specific public key, and a digital signature of the firmware-module image prepared using a module-specific private key.

TECHNICAL FIELD

The present invention relates to secure computer systems.

BACKGROUND OF THE INVENTION

The present invention is related to computer-system security, inparticular, to the process by which a secure computing platform isbootstrapped during initialization or restart of a secure computingplatform, including secure firmware and optionally including a securekernel. The techniques of the present invention are, however,potentially applicable to many other secure-computing problems.

FIGS. 1A-C illustrate a secure-computing-platform booting problemdescribed below as an example of the application of one embodiment ofthe present invention. FIG. 1A shows a number of components of acomputer system, including: (1) a processor 102; (2) a read-only memory(“ROM”) 104, soldered into the system for security reasons, discussedbelow, that stores the first instructions/routine 106 executed by theprocessor following a hard reset or boot; (3) two flash memories 108 and110 that contain a number of firmware modules 112-117 that are runduring system bootstrap, and some of which that are subsequently calledas library routines through various interfaces by an operating system;(4) a system bus 120; (5) a bus bridge 122 interconnecting the systembus 120 with a peripherals bus 124; (6) an I/O controller 126 thatcontrols a mass-storage device 128, such as a disk drive; and a systemmemory 130. As shown in FIG. 1A by arrow 132, following a hard reset orpower on, the processor 102 is hardwired to fetch initial instructions,or, equivalently, an initial routine or set of routines 106, from theROM memory 104. Because a secure system is to be bootstrapped, theinitial routine or set of routines needs to be verifiably secure. Thus,the computer-system manufacturer creates the initial routine or routinesand verifies their security, and places them on a true ROM that cannotbe overwritten and can only be replaced by physically removing the ROMfrom the computer system. Once the initial routine or routines areexecuted, the computer system proceeds to successively access andexecute firmware modules 112-115 incorporated into one of the flashmemories 108, as shown in FIG. 1B. Then, as shown in FIG. 1C, additionalfirmware modules 116 and 117 in another flash memory 110 are accessedand executed. Eventually, one or intermediate phases are reached, afterwhich an operating system kernel can be loaded from the mass-storagedevice 128 into memory and the operating system can be securely bootedto produce a fully functional, secure computer system.

The bootstrap discussed above with reference to FIGS. 1A-C beginssecurely, with routines extracted from a true ROM memory, but when thefirst firmware module in flash memory is accessed, security mechanismsmust be in place to validate the security of the firmware module. Flashmemories may be rewritten, and can thus be maliciously altered after thecomputer system has been shipped from the manufacturer. While the ROMcan be depended on to be secure, the first routines executed from theROM must validate the first firmware module accessed, and each firmwaremodule successively accessed must be verified. This verification cannotdepend on retrieving information from outside of the computer system,and may not even be able to access information stored on mass-storagedevices or on other peripheral devices.

Various techniques have been developed for facilitating a secure bootprocess, a portion of one example of which is illustrated in FIGS. 1A-C.There are various integrated circuits devoted specifically to securitypurposes, such as the Trusted Computing Platform Alliance (“TCPA”)trusted platform module (“TPM”). Certain modern computer architecturesprovide simple machine checking of a portion of an initial firmwareimage. In addition, various rather elegant cryptography-basedmethodologies have been proposed for general authentication andvalidation of software executables. However, each of these types oftechniques and methodologies for addressing the secure-boot problem haveattendant disadvantages and deficiencies. The TCPA TPM chip may requireexpensive engineering to be incorporated into a secure computingenvironment. The simple machine checking cannot be performed to validateand authenticate third-party firmware images loaded during a secureboot. Many of the elegant cryptography solutions require storage ofcryptographic keys in ways that create vulnerabilities at the hardwarelevel. For these reasons, designers, manufacturers and users ofcomputing systems have recognized the need for a relatively inexpensive,secure, and reliable method for authenticating and validating firmwaremodules during sequential loading up and building of a secure kernel ormonitor via a secure bootstrap process.

SUMMARY OF THE INVENTION

Various embodiments of the present invention provide methods forpreparing authenticable and verifiable images of a software modules byadding to received software module images a size and location block, anauthentication block including a cryptographically protectedmodule-specific public key and a clear-text version of themodule-specific public key, and a verification block that includes adigital signature prepared from the module image. In one particularembodiment of the present invention, a next firmware-module that is tobe accessed during a secure boot process is created to include amodule-specific public key, a hashed and encrypted version of themodule-specific public key, and a digital signature of thefirmware-module image prepared using a module-specific private key.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-C illustrate a secure-computing-platform booting problemdescribed below as an example of the application of one embodiment ofthe present invention.

FIG. 2 illustrates a basic principle underlying cryptographicmethodologies.

FIG. 3 illustrates preparation of a firmware module compatible with theloading techniques of one embodiment of the present invention.

FIGS. 4-7 illustrate the firmware-module-image authentication andverification process used by a calling module to authenticate and verifya firmware module prepared as described with reference to FIG. 3.

DETAILED DESCRIPTION OF THE INVENTION

In one particular embodiment of the present invention, a nextfirmware-module that is to be accessed during a secure boot process iscreated to include a module-specific public key, a hashed and encryptedversion of the module-specific public key, and a digital signature ofthe firmware-module image prepared using a module-specific private key.A calling firmware module that directs loading of the next firmwaremodule, according to one embodiment of the present invention, employs acalling-module-specific public key to decrypt the hashed and encryptedmodule-specific public key included in the next firmware module andcompare the resulting decrypted, hashed module-specific public key to ahashed, clear-text module-specific public key included in the nextfirmware module. If the decrypted, hashed module-specific public key isequal to a hashed, clear-text module-specific public key, then, as asecond step, the calling firmware module hashes the next-firmware-moduleimage and compares the hashed next-firmware-module image with a hashednext-firmware-module image extracted from the digital signature includedwithin the next firmware-module image using the module-specific publickey. If the two hashed firmware-module images match, then the callingfirmware module is guaranteed that the next firmware-module isauthentic, or, in other words, was produced by the party assumed to haveproduced the next firmware-module by the calling firmware module, andthat the next firmware-module is verified, or, in other words, the nextfirmware-module has not been modified or corrupted since it wasproduced.

One embodiment of the present invention relates to a secure bootstrapprocess that is initiated upon power up or reset of a secure computersystem and that leads to sequential access and execution of variousfirmware modules, and perhaps software modules, leading to anintermediate, secure state in the secure bootstrap process from which anoperating system can be launched to produce a fully functional andrunning secure computing platform. Were all the firmware modulesproduced by the hardware vendor, and were all the firmware modules ableto be stored in read-only memory within the computer hardware, thetechniques of the present invention would be of less importance.However, modern secure computing systems are complex combinations ofhardware platforms, firmware, and software secure kernels and operatingsystems that are not produced by a single vendor. Therefore, a flexible,but secure, technique for authenticating and verifying modules duringsequential bootstrapping of a secure computing environment are of greatimportance in the design, manufacture, and use of secure computingsystems.

The present invention relies on a combination of several well-knowncryptographic methodologies, a summary of which is provided in afollowing subsection. Following the presentation of these well-knowncryptographic methodologies, the present invention is described withreference to a number of block-diagram-like and control-flow-likediagrams.

Cryptography

The present invention employs cryptographic methodologies in order tosecure communications between an administrative console, or host, andremote agents. In this subsection, the basic cryptographic methodsemployed are described in general terms. FIG. 2 illustrates a basicprinciple underlying cryptographic methodologies. Cryptography isdesigned to transform plain text information into encoded informationthat cannot be easily decoded by unauthorized entities. For example,FIG. 2 shows a plain text message 202 that includes an English-languagesentence. This plain text message can be encrypted by any of variousencryption functions E 1904 into a corresponding cipher text message 206that is not readily interpretable. An authorized user is provided with adecryption function D 208 that allows the authorized user to decrypt thecipher text message 206 back to the plain text message 1902.

The basic cryptographic methods can be described using the followingdefinitions: $\begin{matrix}{A_{m} = {{{alphabet}\quad{for}\quad{messages}} = \left\{ {a_{m_{1}},a_{m_{2}},{a_{m_{3}}\quad\ldots\quad a_{m_{n}}}} \right\}}} \\{A_{c} = {{{{alphabet}\quad{for}\quad{cipher}} - {text}} = \left\{ {a_{c_{1}},a_{c_{2}},{a_{c_{3}}\quad\ldots\quad a_{c_{n}}}} \right\}}} \\{M = {{{message} - {space}} = {{strings}\quad{of}\quad a_{m}}}} \\{C = {{{cipher} - {{text}\quad{space}}} = {{strings}\quad{of}\quad a_{c}}}} \\{K = {{{key}\quad{space}} = \left. {\left\{ {e_{1},{e_{2}\quad\ldots\quad e_{n}}} \right\}\quad{where}\quad{E_{e_{i}}(m)}}\rightarrow c \right.}} \\{= \left. {\left\{ {d_{1},{d_{2}\ldots\quad d_{n}}} \right\}\quad{where}\quad{D_{d_{i}}(d)}}\rightarrow m \right.}\end{matrix}$Plain text messages are instances of messages contained within themessage space M and cipher text messages are instances of the ciphertext messages contained within cipher test space C. A plain text messagecomprises a string of one or more characters selected from a messagealphabet A_(m), while a cipher-text message comprises a string of one ormore characters selected from the cipher-text alphabet A_(c). Eachencryption function E employs a key e and each decryption function Demploys a key d, where the keys e and d are selected from a key space K.In a symmetric-key encryption system, the keys e and d are identical,and the secret distribution and maintenance of the symmetric keys insecret provide security. In an asymmetric-key encryption system, thekeys e and d are different. The following discussion relates toasymmetric encryption systems.

A key pair is defined as follows:key pair=(e, d)where eεK, dεK, D_(d)(E_(e)(m))=E_(e)(m), and mεMOne key of the key pair, e, is used during encryption to encrypt amessage to cipher text via an encryption function E, and the other keyof the key pair, d, can be used to regenerate the plain text messagefrom the cipher-text message via a decryption function D. In symmetric.

Public-key cryptographic methods are encryption/decryption techniquesemploying key pairs (e,d) having the property that, for all key pairs(e,d), no function f(e)=d can be easily determined. Thus, the encryptionkey e of a public-key pair (e,d) can be freely distributed, because thecorresponding decryption key d of the public-key pair cannot bedetermined from the encryption key e. A well-known example of public-keyencryption is the RSA encryption scheme. The RSA scheme employs integerdivision of large numbers, generated from plain text and cipher-textmessages, by large integers n that represent the product of two primenumbers p and q as follows:E(m)=m ^(e) mod nD(c)=c ^(d) mod ned mod(p−1)(q−1)=1n=pqThus, a plain text message is encrypted by considering all of thenumeric representations of the characters of the message to be a largenumber, computing the result of raising the large number to a powerequal to the encryption key e, dividing that result by n, and using theremainder of the division as the encrypted message. Decryption employsthe same process, raising the cipher-text message to a power equal tothe decryption key d, then regenerating the plain text message byconsidering the remainder, followed by division by n, as a string ofnumerically represented characters.

A digital signature is a value generated from a message that can be usedto authenticate the message. The digital signature space S contains allpossible digital signatures for a particular digital signature algorithmapplied to messages selected from message space M. Generation of adigital signature involves a secretly held digital signature generationfunction SA applied to a message:S _(A)(m)→sThe digital signature s is sent, along with the message m from which thedigital signature is generated, to a recipient. The recipient employs apublic verification function V_(A) to determine whether the digitalsignature authenticates the message or, in other words, whether themessage was composed by the signer, and has not been modified in theinterim. Thus, V_(A) can be expressed, as follows:V _(A)(m,s)→{true,false}where the result true indicates that the message m was composed by thesigner who provided the digital signature s.

A digital-signature system can be generated from a reversible public-keyencryption system, defined as follows:for all m, D _(d)(E _(e)(m))=E _(e)(D _(d)(m))where the message space, M=the cipher space, C=the digital signaturespace, S. The digital-signature-generating function S_(A) can beselected as:S_(A)=D_(d)so that:S=D _(d)(m)The verification function V_(A) can then be selected as:${V_{A}\left( {m,s} \right)} = \left\{ \begin{matrix}{{true},\quad{{{if}\quad{E_{e}(s)}} = m}} \\{{false}\quad}\end{matrix} \right.$

Thus, the techniques of the public key encryption technique can be usedto generate digital signatures that can, in turn, be used by a digitallysigned message recipient, to verify that a message was sent by the partysupplying the digital signature. While it is generally feasible todigitally sign entire, short email messages, it is rather inefficient todigitally sign large amounts of data, such as an executable image. Amore efficient way to digitally sign a large amount of data, such as anexecutable image, is to first digitally hash the large amount of data toa hash value, and then digitally sign the hash value. An efficienthashing function is required that produces a relatively small hash valuefrom a large amount of data in a way that generates large distances inhash-value space between hash values generated from data inputsrelatively close together in data-input space. In other words, smallchanges to input data should widely disperse generated hash values inhash-value space, so that the hash function cannot be deducedsystematically. One example of a hash function widely used for thispurpose is the Secure Hash Algorithm (“SHA-1”) specified by the SecureHash Standard, available at the web site specified by the URL:http://www.itl.nist.gov/fipspubs/fip180-1.htm. The SHA-1 secure hashalgorithm generates a 160-bit hash value, called a message digest, froma data file of any length less than 2⁶⁴ bits in length. The SHA-1algorithm is a secure hash because it is computationally infeasible tofind a message which corresponds to a given message digest, or to findtwo different messages which produce the same message digest.

Secure-Boot Embodiment of the Present Invention

One embodiment of the present invention provides a method by which acalling firmware module or combination of firmware modules canauthenticate and verify a next firmware module that needs to accessed,possibly executed, and incorporated into the processing environment of asecure computing system. FIG. 3 illustrates preparation of afirmware-module image compatible with the authentication andverification techniques of one embodiment of the present invention. FIG.3 includes both block diagrams and flow-control-like annotations.

The process of constructing the authenticable and verifiablefirmware-module image begins with a firmware image 301 that includes animage size, location, and globally unique identifier (“GUID”) header(“ISLGUID”) 302 that serves to describe the size and location of thefirmware image within a flash memory or other non-volatile memory and toidentify, via the GUID, the class of machines for which the firmwaremodule has been created. By accessing the ISLGUID header, a callingmodule accessing firmware-module can determine where to find additionalinformation in order to authenticate and verify the firmware module.Note that the ISLGUID block does not necessarily need to be a header, asshown in FIG. 3, but may be incorporated into the firmware-module imageat any specific, commonly known location to allow access by a callingmodule.

In a next step in the preparation of the authenticable and verifiablefirmware-module image, a secure hash function, such as the SHA-1 securehash function described above, is used to hash a public encryption key(“PK2_(P)”) 303 associated with the firmware module to produce a hashedpublic key, or message digest, 304 corresponding to the public key“PK2_(P).” Next, the firmware-module developer provides the hashedpublic key “PK2_(P)” to the vendor of the calling firmware module, whouses a private key “PK1_(V)” 305 to encrypt the hashed PK2_(P) 304 toproduce an encrypted, hashed, module-specific public key “PK2_(P)*” 306that the calling-firmware-module vendor returns to the firmware-moduledeveloper. The hashed, encrypted public key “PK2_(P)*” 306 is placed,along with the clear-text version of public key “PK2_(P)” into anauthentication header 308 that is prepended to the firmware-module image301. The private key “PK1_(V)” is a secret key used by the vender ormanufacturer of the calling firmware module. In general, the private key“PK1_(V)” will be kept secure by the calling module's manufacturer,never disclosing the private key “PK1_(V)” to any third party. Becausethe encryption key “PK2_(P)” is a public encryption key associated withthe firmware-module image, the public encryption key “PK2_(P)” can befreely furnished by the vendor of the firmware-module image to thirdparties.

Next, the agreed-upon secure hash algorithm is used to hash the contentsof the firmware-module image 301, excluding the prepended authenticationheader 308, and the resulting message digest is encrypted with a privateencryption key “PK2_(V)” 310 corresponding to the public encryption key“PK2_(P)” 303. The hashing and encryption operations are shown in FIG. 3as step 312. The hashing and encryption of the firmware-module image 312produces a digital signature which is appended to the firmware-moduleimage as a verification footer 314.

The completed authenticatable and verifiable firmware module thuscomprises an authentication header 308 including a hashed and encryptedpublic key “PK2*_(P)” and clear-text version of the public key“PK2_(P),” the firmware module 301 including an ISLGUID block 302, and averification footer that includes a digital signature 314. Note thatboth the authentication header 308 and verification footer 314 may bealternatively included within the firmware module at specific, commonlyknown locations, may be both prepended or appended to the firmwaremodule, or may be packaged as discrete entities along with the firmwaremodule. In the discussed embodiment, the authentication block isprepended as a header and the verification block is appended as afooter, as shown in FIG. 3.

FIGS. 4-7 illustrate the firmware-module-image authentication andverification process used by a calling module to authenticate and verifya firmware module prepared as described with reference to FIG. 3. Theaccessed firmware module is referred to as the “next firmware module.”In FIG. 4, the calling firmware module 402 is shown abstractlyincorporated within the current execution environment of a securecomputer system 404. Note that the calling module includes a storedversion of the calling module's public encryption key “PK1_(P)” 406.

FIG. 5 illustrates the first step of the authentication process thatrepresents a portion of one embodiment of the present invention. In FIG.5, the calling module 402 accesses the ISLGUID block 302 of the nextfirmware module. The calling module 402 accesses the ISLGUID block inorder to first check the GUID included in the ISLGUID to make sure thatthe next firmware module is intended for the machine on which it hasbeen loaded, and to then determine the sizes and locations of therelevant portions of the next firmware module, including theauthentication header 308, the firmware-module image 301, and theverification footer 314.

As shown in FIG. 6, the calling module 402 next accesses theauthentication header, extracting from the authentication header thehashed, encrypted public encryption key “PK2_(P)*” associated with thenext firmware module 306. The calling module 402 then employs its publickey “PK1_(P)” 406 to decrypt the encrypted, hashed public key “PK2_(P)*”to produce a hashed public key “PK2_(P)” 602. Then, the calling module402 extracts the clear-text public encryption key “PK2_(P)” from theauthentication header 308 and hashes the clear-text public encryptionkey “PK2_(P)” 604, and then compares 606 the extracted hashed PK2_(P)with the decrypted, hashed PK2_(P) 602 in order to determine whether ornot the next firmware module is an authentic firmware module. If thedecrypted, hashed PK2_(P) 602 is identical to the extracted hashedPK2_(P) 604, then the next firmware module is an authentic firmwaremodule produced by the firmware module vendor after receiving thehashed, encrypted public encryption key “PK2_(P)*” from the vendor ofthe calling module 402. After the next firmware module is authenticated,the verification portion of the authentication and verification processensues, described below with respect to FIG. 7. Otherwise, as indicatedby the negative arrow 608 in FIG. 6, the authentication portion of theauthentication and verification process fails, and the calling module402 may take appropriate action. The calling module 402 may, forexample, display an authentication failure message to a console andterminate the bootstrap process.

The verification portion of the authentication and verification processthat represents one embodiment of the present invention is illustratedin FIG. 7. In the verification portion of the process, the callingmodule hashes the firmware-module image 301, including the ISLGUID block302, and then compares 707 the hashed firmware-module image 706 with ahashed firmware-module image 708 obtained by extracting the digitalsignature stored in the verification footer 314 appended to the firmwaremodule and decrypting 709 the digital signature with the module-specificpublic encryption key “PK2_(P).” If the extracted and decrypted digitalsignature is equal to the digital signature 706 produced in the hashingstep 702, then the next firmware-module image has been bothauthenticated and verified, as indicated by the positive arrow 710 inFIG. 7. Otherwise as indicated by the negative arrow 712 in FIG. 7, theverification step has failed. Again, the calling module can takeappropriate steps upon failure and success.

The authentication portion of the authentication and verificationprocess thus authenticates a next firmware module as having beenproduced by the expected vendor. No other vendor or malicious firmwareproducer can include the hashed and encrypted public key “PK2_(P)*” intothe authentication header 308. The verification portion of theauthentication and verification process ensures that the firmware-moduleimage produced by the authenticated firmware vendor has not been alteredor corrupted since being produced by the firmware-module vendor. Byundertaking the authentication and verification process illustrated inFIGS. 4-7, the calling module can confidently access, execute, and/orincorporate the next firmware-module image within the secure-systemexecution environment without compromising the security of the securesystem.

Although the present invention has been described in terms of aparticular embodiment, it is not intended that the invention be limitedto this embodiment. Modifications within the spirit of the inventionwill be apparent to those skilled in the art. For example, as discussedabove, a next firmware-module image may include the ISLGUID block,authentication block, and verification block in various differentlocations within the authenticatable and verifiable firmware-moduleimage. While the technique of one embodiment of the present inventionhas been described with respect to a secure-boot procedure thatsequentially accesses, executes, and/or incorporates firmware modulesinto a secure system, the same technique can be applied to softwaremodules and to other instruction-containing entities. Specificcryptographic methodologies are used in the disclosed embodiment, butmany comparable and equally effective cryptographic methodologies mayalternatively be employed. For example, various different secure hashalgorithms are available, and it may be possible to employ anothermethod to produce a small, easily encrypted portion of a next image.

The foregoing description, for purposes of explanation, used specificnomenclature to provide a thorough understanding of the invention.However, it will be apparent to one skilled in the art that the specificdetails are not required in order to practice the invention. Theforegoing descriptions of specific embodiments of the present inventionare presented for purpose of illustration and description. They are notintended to be exhaustive or to limit the invention to the precise formsdisclosed. Obviously many modifications and variations are possible inview of the above teachings. The embodiments are shown and described inorder to best explain the principles of the invention and its practicalapplications, to thereby enable others skilled in the art to bestutilize the invention and various embodiments with various modificationsas are suited to the particular use contemplated. It is intended thatthe scope of the invention be defined by the following claims and theirequivalents:

1. A method for preparing an authenticable and verifiable image of amodule, the method comprising: receiving a module image; adding to themodule image a size and location block; adding to the module image anauthentication block including a cryptographically protectedmodule-specific public key and a clear-text version of themodule-specific public key to produce an authenticable image; and addingto the authenticable image a verification block that includes a digitalsignature prepared from the module image.
 2. The method of claim 1wherein adding to the module image a size and location block furtherincludes: adding, in a specific location, a header that includes animage size, location, and globally unique identifier describes a sizeand location of the firmware image within a flash memory or othernon-volatile memory and that identifies a class of machines for whichthe firmware module has been created.
 3. The method of claim 1 whereinadding to the module image an authentication block including acryptographically protected module-specific public key and a clear-textversion of the module-specific public key to produce an authenticableimage further includes: adding to the module image an authenticationblock including an encrypted, hashed module-specific public key and aclear-text version of the module-specific public key to produce anauthenticable image.
 4. The method of claim 1 wherein adding to theauthenticable image a verification block that includes a digitalsignature prepared from the module image further includes: adding to theauthenticable image a verification block that includes a digitalsignature prepared by hashing the module image and encrypting the hashedmodule image with a module-specific private key.
 5. Computerinstructions that together compose a program that carries out the methodof method of claim 1 stored in computer readable medium.
 6. A method forauthenticating and verifying an authenticable and verifiable module, themethod comprising: extracting, from the authenticable and verifiablemodule, a module-specific public key and cryptographically protecteddata related to the module-specific public key; comparing thecryptographically protected data with the module-specific public key toauthenticate the authenticable and verifiable module; comparing a valuecalculated from an image, including a size and location block, includedwithin the authenticable and verifiable module a value extracted from adigital signature contained in a verification block within theauthenticable and verifiable image to verify the authenticable andverifiable module.
 7. The method of claim 6 wherein extracting, from theauthenticable and verifiable module, a module-specific public key andcryptographically protected data related to the module-specific publickey further includes: extracting, from an authentication block at aknown location within the authenticable and verifiable image, anencrypted, hashed module-specific public key and a clear-text version ofthe module-specific public key.
 8. The method of claim 7 whereincomparing the cryptographically protected data with the module-specificpublic key to authenticate the authenticable and verifiable imagefurther includes: hashing the clear-text version of the module-specificpublic key to produce a newly hashed module-specific public key;decrypting the encrypted, hashed module-specific public key using afirst private encryption key; and comparing the decrypted, hashedmodule-specific public key with the newly hashed module-specific publickey.
 9. The method of claim 8 wherein, when the decrypted, hashedmodule-specific public key is identical to the newly hashedmodule-specific public key, the authenticable and verifiable image isdetermined to be authenticated.
 10. The method of claim 6 whereincomparing a value calculated from an executable image, including a sizeand location block, included within the authenticable and verifiableimage a value extracted from a digital signature contained in averification block within the authenticable and verifiable image toverify the authenticable and verifiable image further includes: hashingan executable image, including a size and location block, includedwithin the authenticable and verifiable image to produce a newly hashedimage; extracting a digital signature from a verification block withinthe authenticable and verifiable image, and decrypting the digitalsignature using the module-specific public key to produce an extractedhashed image; comparing the extracted hashed image to the newly hashedimage.
 11. The method of claim 10 wherein, when the extracted hashedimage is identical to the newly hashed image, the authenticable andverifiable image is determined to be verified.
 12. The method of claim 6employed during secure access, execution, and/or incorporation of theauthenticable and verifiable image into a secure-computer processingenvironment, wherein, when the authenticable and verifiable image isauthenticated and verified by the method of claim 6, the authenticableand verifiable image is accessed, executed, and/or incorporated, andwhen the authenticable and verifiable image is not authenticated or notverified, the authenticable and verifiable image is not executed and/orincorporated.
 13. The method of claim 12 employed in the secure bootingof a secure computer system, wherein, when an authenticable andverifiable image is not executed and/or incorporated, the secure bootfails.
 14. Computer instructions that together compose a program thatcarries out the method of method of claim 6 stored in computer readablemedium.
 15. An authenticable and verifiable image of an module stored ina computer-readable medium comprising: a module image, including a size,location, and globally unique-identifier block; an authentication block;and a verification block.
 16. An authenticable and verifiable image ofan module of claim 15 wherein the authentication block contains anencrypted, hashed module-specific public key and a clear-text version ofthe module-specific public key to produce an authenticable image.
 17. Anauthenticable and verifiable image of an module of claim 15 wherein theverification block that includes a digital signature prepared by hashingthe module image and encrypting the hashed module image with amodule-specific private key.
 18. A method for preparing an authenticableand verifiable image of a module, the method comprising: a module-imagereceiving step; a size-and-location-data adding step that addssize-and-location data to the received module image; anauthentication-adding step that adds, to the module image,authentication information including a cryptographically protectedmodule-specific public key and a clear-text version of themodule-specific public key; and a verification-block-adding step thatadds a digital signature prepared from the module image to the moduleimage.